Test three cases:
- Empty allow list permits injection from any registry (backward compat)
- Registry in allow list permits injection
- Registry not in allow list blocks injection and sets error annotation

…-allow-list-webhook

Replace global.containerRegistryAllowList approach with setting
DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_CONTAINER_REGISTRY_ALLOW_LIST
directly via clusterAgent.env, so the test works with the current helm
chart version without needing the helm-charts PR to merge first.

Two test cases:
- TestRegistryAllowListBlocked: allow list = fake.registry.invalid,
  injection is blocked and error annotation is set
- TestRegistryAllowListAllowed: allow list = registry.datadoghq.com
  (the injector's registry), injection proceeds and traces arrive

Deploy two apps in the same cluster with allow list = registry.datadoghq.com:
- registry-allow-list-allowed: uses default injector, injection proceeds
- registry-allow-list-blocked: pod annotation overrides injector image to
  fake.registry.invalid (not in allow list), injection is blocked

This avoids a second UpdateEnv call (and second cluster setup) by using the
admission.datadoghq.com/apm-inject.custom-image annotation to point one pod
at an injector registry that is not in the allow list.

The previous check only validated the injector image registry. A user
could bypass the allow list by annotating a pod with
admission.datadoghq.com/python-lib.custom-image pointing to an
arbitrary registry.

Now InjectAPMLibraries checks every library's registry against the
allow list in addition to the injector's registry.

Adds a unit test for the library registry case and a third e2e scenario
(LibraryRegistryBlockedByAllowList) that uses a python-lib.custom-image
annotation pointing to fake.registry.invalid to verify the check fires.

Two bugs:

1. kpiEnvVarsMutator (which sets DD_INSTRUMENTATION_INSTALL_TYPE) runs
   before apmInjectionMutator (which contains the allow list check in
   InjectAPMLibraries). Blocked pods were getting DD_INSTRUMENTATION_INSTALL_TYPE
   set even though injection was blocked, causing RequireNoInjection to fail.
   Fix: add the allow list check at the start of injectTracers, before any
   mutators run.

2. Our clusterAgent.env override in the test YAML replaced the framework's
   default env list, losing GRADUAL_ROLLOUT_ENABLED=false. With gradual
   rollout enabled the injector image resolver may return an image from a
   different registry (not registry.datadoghq.com), causing the allow list
   check to block even the "allowed" pod. Fix: add GRADUAL_ROLLOUT_ENABLED=false
   back to the test YAML alongside our allow list env var.

…stry)

The default admission_controller.container_registry is gcr.io/datadoghq,
so injector and library images both come from gcr.io/datadoghq in the
test environment. The allow list was set to registry.datadoghq.com which
does not match, causing the allow list check to block the 'allowed' pod.

InjectAPMLibraries has only one production caller (namespace_mutator.go),
which already runs the allow list check before any mutators. The check
inside InjectAPMLibraries was redundant. Remove it and the unit tests
that covered it at that level.

…-allow-list-webhook

…-allow-list-webhook

Without admission.datadoghq.com/enabled, the target-based path takes
over and the python-lib.custom-image annotation is ignored. The pod
gets injected with the target-configured image (gcr.io/datadoghq),
which is in the allow list, so the test incorrectly fails.

Add the enabled label so the annotation-based path processes the
custom-image annotation, which the allow list then correctly blocks.

…-allow-list-webhook